home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / cbm / 2829 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.9 KB
  1. Path: diku.dk!diku2471
  2. From: diku2471@diku.dk (ASGER ALSTRUP NIELSEN)
  3. Newsgroups: comp.sys.cbm
  4. Subject: Re: anyone doing heavy math on a c64?
  5. Date: 17 Feb 1996 19:43:28 GMT
  6. Organization: Department of Computer Science, U of Copenhagen
  7. Sender: diku2471@fjalar.diku.dk
  8. Message-ID: <4g5b50$70h@odin.diku.dk>
  9. References: <4e2l0q$n8f@turing.fwi.uva.nl> <4f49t9$2q5@madeline.INS.CWRU.Edu> <4fchhs$2r1@tor.abc.se> <4ftcnm$bfs@news.acns.nwu.edu> <DMsHCw.8G0@undergrad.math.uwaterloo.ca>
  10. NNTP-Posting-Host: odin.diku.dk
  11. X-Newsreader: NN version 6.5.0 #13
  12.  
  13. csbruce@ccnga.uwaterloo.ca (Craig Bruce) writes:
  14.  
  15. >In article <4ftcnm$bfs@news.acns.nwu.edu>, Stephen Judd <sjudd@nwu.edu> wrote:
  16.  
  17. >>Peter T Karlsson <dat95pkn@idt.mdh.se> wrote:
  18. >>>C=64+64*INT(.1+.9)
  19. >>>
  20. >>>will give C 64 for a C64 and 128 on a C128!
  21. >>
  22. >>I find this very interesting.  Does anyone have an explanation for this?
  23.  
  24. >Floating-point arithmetic is a bit of a crap shoot anyway.  Maybe they subtly
  25. >changed the addition code between the two versions, or...
  26.  
  27. Maybe, but I doubt the change is the addition code as such. It is probably
  28. in some internal rounding function instead, see below.
  29.  
  30. >I have some vague notions about the floating-point accumulators (FACs)
  31. >storing a number with slightly more precision than a floating-point
  32. >variable, so this may be what is happening.  If the number doesn't have to
  33. >leave the FACs (which it doesn't in the above first example), then there may
  34. >be a slightly different answer from if it does.  Maybe the C128 stores or
  35. >doesn't store intermediate results from the FACs while the C64 doesn't/
  36. >does.
  37.  
  38. I think, I remember that the floating point routines are bugged. It's correct
  39. that it uses higher precision when calculating than when storing, but the
  40. lsbs of the FACs aren't always reset properly between operations, so you 
  41. can have situations where the same arithmetical expression yields
  42. different results depending on what the lsbs of the FACs contain at that
  43. particular point. Maybe they fixed the initialization bug in the c128 rom
  44. and this could explain the difference.
  45.  
  46. Other than that, the floating point operations of the c64 are not exactly
  47. the best in the business, but they candidate for the smallest in bytes.
  48. The coders did a lot of tricks to pack up all that functionality into such
  49. small space. This affects performance: For instance, the sqr() function
  50. is calculated as x^0.5, which is a far shot from a fast method. If you
  51. use sqr a lot, it pays a lot to use a custom routine. The german magazine
  52. 64er once held a contest to find the best sqr-routine, and the winner used 
  53. a lookup table to give a start-value for a newton-ralphson search and was
  54. many times faster than the original code besides a lot more precise, and 
  55. still around 256 bytes in size. The guys behind the basic rom simply didn't 
  56. have those 256 bytes to do it better, and then again, they would probably 
  57. have crammed another function in instead of a faster squareroot ;-)
  58.  
  59. Greets,
  60.  
  61. Asger Alstrup.
  62.